• Data – This is the foundation of the platform and includes the data pipeline and core information architecture.
• Marketplace – The host of systems aimed at improving efficiency within the marketplace; including the matching algorithm, methods through which we abstract relevant features of supply and demand to feed the matching algorithm (e.g. proximity score, win-rate), and applications used to codify useful market observations.
• UI – The various interfaces that enable users to engage within the platform in increasingly productive ways. There UI component has several important functions. First, the more it enables users to perform, the less we have to help them. Second, the more users we have engaging on the platform in meaningful ways, the more signal we’re able to compile and feed into the Data component.

The flywheel works something like this:

1. We use public data to gain a big head start in terms of understanding the market.
2. The marketplace component uses this data to enable efficient market interactions.
3. The UI component fosters user engagement. This user engagement creates additional data that is fed back into the data component, giving it more ammunition, which in turn enables more efficiencies in the market.

Much of this essay will focus on the UI paradigm as the gateway through which we perpetually compile valuable market data, which enables the flywheel’s momentum to increase (and perpetually improve the market’s efficiency).

The Legacy UI Paradigm

Here is one way to visualize the legacy paradigm:

Our initial hypothesis was that BuildZoom is a two-sided marketplace. The platform should connect supply with demand. Therefore, the UI should enable demand users to create a project description, view their matches, and ultimately select one. In the diagram above, functionality for demand users is represented as set D. Supply users need functionality to pursue leads and manage their pipelines. This functionality is represented by Set S. There is an intersection between these sets (S ⋂ I), best exemplified in the communication application we developed.

As you can see, there is a third set ‘Intermediary’ (I), which I use to refer to what we’ve historically called our ‘back office tools.’ In the legacy paradigm, the human roles within BuildZoom were limited to qualifying demand users, onboarding supply users, and working with supply users to collect referral fees. Technology built to support these functions was considered outside the scope of our platform strategy and often a secondary consideration in roadmap planning.

The Shortcomings of the Legacy Paradigm

While our legacy platform strategy shares similarities with companies like HomeAdvisor and Thumbtack that have generated significant revenue via a CPL model, it was not well-suited to the CPA model or the construction segment (which includes residential alterations, residential construction, and commercial alterations) we are addressing for several reasons.

Monetization Advantage – In a CPL model, the average lead value caps out as contracts increase in size. By taking a percentage of the gross contract, the unit value grows at a commensurate rate with the size of the contract. At a 15% conversion rate, we’re essentially able to extract 4x the revenue as the CPL model for a $250K contract. This monetization advantage is particularly important in the long-run as it enables us to buy all the demand of this type.

Supply quality – We learned early on, that premium GC’s and builders, tend to have a backlog of opportunities and are far less inclined to pay for leads they have to qualify and chase. However, they are willing to work with us when presented with a qualified opportunity that fits their business and only charged upon acquisition of a contract,

Incentive alignment – Finally, the CPL model dictates a strategy that results in routing demand to the supply willing to pay the most for leads; whereas the CPA model compels us to find the best actual match between supply and demand.

Ever since we made the decision to shift fully to the CPA model, the most significant business problem has been over how we monetize large construction opportunities. Not only have these opportunities represented a majority of the gross contract value (GCV) associated with leads, but this also represents a true greenfield opportunity in the market.

The Breakthrough

Through 2018, two breakthroughs formed the basis for what has become our repeatable sales model: First, the growth team’s efforts resulted in what we refer to as the ‘high touch’ sales motion; second, the BD team’s efforts ultimately evolved into what we refer to as ‘BuildZoom Premium.’ The synthesis of these two initiatives forms the basis for a sales model that:

• Enables us to increase our overall take rate.
• Significantly increases our conversion rate, which enables us to out-monetize competitors for demand.
• Monetize earlier in the process by charging the demand side for BuildZoom Premium, which also creates increased financial predictability, and dramatically shortens the time it takes for a rep to make a positive financial contribution.
• Create a greater level of product-market fit through BuildZoom Premium, leading to increased word-of-mouth referral.

Expands our target market to include pre-design opportunities and companies with repeat business (e.g. franchisors).

This new model has fundamentally changed the amount of value that can be created by an individual rep.

Divergence

In order to create the flexibility needed to validate and systematize the sales motion, a lot of interaction was taken off-platform. In 2019, the efficacy of this new sales model is driving much of the business strategy. However, there is an ongoing divergence between the customer UX and the actual UI within the platform.

Addressing the Divergence

BuildZoom’s goal is to be the dominant platform in the construction market. To achieve the next milestone within the next 2-3 quarters, we need to prove out the ability to convert demand into cash in a predictable fashion.

After years of hard work, we understand that achieving product-market fit in the construction market requires a human-in-the-loop (Note: I realize I’m being a bit loose with the application of this term).

There are two roles in particular we have determined are critical to the platform currently:

The Project Consultant (PC)

The PC serves as an intermediary between supply and demand. They fill several important functions. First, they help address the knowledge gap that often exists with Demand. Second, they are able to contextualize the value of Premium, which enables BuildZoom to better serve them. Third, they are able to support the Matching System by connecting with new Supply, but also by logging their interactions and learnings back into the Data System.

Finally, they fill an important psychological need when it comes to large purchases. Think about comparable transactions: for home purchases, you have a real estate agents; for weddings, you have wedding planners. Construction is one of the only major transactions that doesn’t actually have an established intermediary. Opportunistic architects will sometimes play this role, and there are some owner’s reps in the market, but the role is not established.

The Construction Engineer (CE)

The construction engineer plays a critical role in helping us achieve the delivery of value needed to achieve product-market fit in the construction market.

In conclusion, we have realized that a knowledgeable human intermediary is crucial for giving clients the right information, advice, and peace of mind that will enable them to move forward with their projects. Moving forward, I’ll refer to these roles as intermediaries (I).

From a platform perspective, this has some immediate consequences for how we should think about the marketplace layer, and dramatic impact in how to think about the UI layer.

The New UI Paradigm

Instead of looking at the platform as being exclusive to Supply and Demand (S ⋃ D), we need to shift our perspective and think about the UI layer as the union between supply, demand, and intermediaries (S ⋃ D ⋃ I).

Consistent with the legacy paradigm, there are sets for both demand (D) and supply (S). Historically, we have equated these sets to one persona of users each: PO’s to (D) and CO’s to (S).

Instead of just equating each of these sets to a persona of users, we can now think about these sets as containing functionality to support either supply or demand-side activities (in some cases, a contractor or developer may actually be interfacing with the demand-side UI. Additionally, the persona of users who access these interfaces is also broadening. On the supply side, we’re seeing new types of actors, such as architects and structural engineers, playing a role. On the demand side, we’re seeing market actors like property managers and franchises engaging with the platform.

Perhaps the most significant change in the new paradigm involves the emergence of I as an integrated set; and three new intersections: (I ⋂ S), (I ⋂ D), and (I ⋂ S ⋂ D). The evolution of our platform based on what we have learned, calls for a similar evolution in our product strategy.

The following are several ways our product will/may develop: (Note – I’ve removed some of the more proprietary elements from the following list):

Example: Fulfillment of BuildZoom Premium

In the legacy paradigm, the workflow through which Premium deliverables are assigned and sent to D, would be marginalized into set A. In the new paradigm, there is an opportunity to place this initiative in (I ⋂ D), which would systematize the manner in which we assign Premium deliverables to a CE and bill D for the fulfillment of these deliverables. Furthermore, a subsequent iteration would enable passthrough and collaboration around these deliverables between I and D.

Example: Collaboration between I and S

Currently, there are varying forms of engagement that occur between I and S off-platform, necessary to fulfill on Premium. Placing this initiative in (S ⋂ I) would move the engagement on-platform and open the aperture of what’s possible through the UI. Having I and S work on-platform creates opportunities to streamline the process, which decreases the marginal cost associated with fulfillment; but also creates the opportunity to add compounding value into the platform through these interactions.

How the platform evolves over time

In the present, expanding the aperture to account for the intermediary as a key stakeholder in the marketplace, addresses for the reality of what is needed to create a successful marketplace outcome. In the long-term, the goal is to optimize their contribution to our accumulating data advantage, and increase the flywheel’s velocity. This means greater autonomous market efficiency and an increase in the capacity of each intermediary. We’re already seeing this in maturing markets (e.g. the Bay Area), where the marginal effort needed to create a positive market outcome has decreased dramatically.

Conclusion

Our fundamental mission – to be the underlying platform for the construction industry – has remained unchanged. Failing to evolve the paradigm through which we think about the platform’s role in the marketplace, will inevitably lead us down a path with reduced scalability, efficiency, and deprecate our ability to contribute to our accumulating data advantage.

By moving past the old paradigm and embracing the intermediary as a stakeholder group within the platform, we acknowledge the reality of what is needed to create consistently positive outcomes in the marketplace, increased efficiency, and contributing to our accumulating data advantage over time.

This difference could be boiled down to an existential question of whether we want to strive to be a service-oriented company, with a lower ceiling; or a technology platform that accounts for intermediaries, with a much higher ceiling. My preference is the latter.

Each year, there are millions of construction transactions that take place in the market, and continuing to operate within the old paradigm, will result in limiting our ability to influence the overall marketplace. Shifting to the new paradigm will help us fulfill our fundamental mission and sets us on a path that truly aligns our revenue strategy with our product strategy.

There have been a lot of rebuilds taking place in the neighborhood over the past decade or so and to get a better sense for the ROI of one, I took a look at a property down the street. Checking the transactional history, I was able to quickly see how it was purchased in 2007 for $725K and then sold less than a year later for $1.8M.

To quickly determine the investment that resulted in this return, I simply looked up the construction records on BuildZoom to get a sense for the valuation of construction put in place (around $400K).

I acknowledge this is a rudimentary method and probably requires a bit more discovery, however it does provide a good heuristic that can help inform the decision to renovate an existing structure or simply rebuild, based on the actual value created through the construction project, which is made pretty clear based on the transactional records.

Collection Agencies suck. They typically are aggressive and annoying and use a brute force approach to things. Skeptical they are using data or technology to create a more elegant, user-centered approach to the situation.

Solution

If a consumer or business has an outstanding debt that goes to a collection agency, it comes with a penalty to their credit score (and is annoying). By leveraging data & technology, a reimagined collection agency could come up with a far more personalized and contextually-relevant approach to individual consumers; furthermore, they could take steps to a. provide guidance for repairing the debtor’s credit score and b. provide consumer-friendly financing options. Furthermore, seems like a lot of the current entities are human-powered in spite of the routine nature of their interactions; so technology could create some significant cost & operational efficiencies.

Why it could work

Haven’t seen much competition and hard to imagine that building a better collection agency is particularly appealing for many entrepreneurs, which is actually a positive. Doubt that it would be really hard to start taking out legacy collection agencies and a SV start-up could get traction out of the gate by selling into the SV ecosystem.

Why it could fail 

I haven’t researched this enough to provide good reasons this type of venture would fail.

TAM

$11B domestic (IBISWorld)

Towards the end of November, we were contacted by Ms. Theresa Buckley, another attorney from the Office of the Treasurer & Tax Collector, who wanted to have more of an informational chat about their request. She had recently joined Cisneros’ office after spending time in the private sector. Her demeanor was empathetic and I got the sense that she genuinely wanted to understand the situation and our perspective and work towards an amicable resolution.

I re-articulated my view on what I believe to be, an overreaching request for private user information, in addition to my broader perspective that at scale, such requests could be detrimental to the entrepreneur-friendly culture that San Francisco has built over the past several decades. I also reiterated the fact that their request wouldn’t uncover any incremental tax revenue since we already rely on SF building permit data to match contractors, who are already required to have a business tax registration certificate number before doing permitted work in San Francisco. Ms. Buckley did acknowledge this point and said she would discuss with her team although she didn’t outright drop their request for information. She did seem intent on assuring us that even if we were to disclose private information to the SF tax collector, they had a strict confidentiality policy to protect any participating companies.

November 13, 2017

This past week, I was pleased when Laurel Arvanitidis, the Director of Business Development from the Office of Economic and Workforce Development, reached out to discuss our situation. She was incredibly knowledgeable and helpful. After our call, my interpretation is that much of the situation results from José Cisneros’ ability to interpret and execute on San Francisco Tax Regulations Codes – in particular, sections 6.4-1 and 6.5-1, with what seems like impunity.

6.5-1 in particular, seems to give Cisneros the ability to ask just about any company for anything: “Financial information” shall include, but not be limited to, bank records, journals, ledgers and local, State and federal tax returns, and shall include information regarding subsidiary, related, affiliated, controlled or controlling persons in possession of information relevant to the Tax Collector’s inquiry.”

So basically, my current interpretation is that José Cisneros takes 6.5-1 to mean that he can ask any technology company that provides services in San Francisco for just about anything because the definition of ‘relevant’ is so vague.

Fortunately for us, Arvanitidis also informed us that what Cisneros is primarily looking to exploit the tax code to ensure that any business entity in San Francisco is operating with an active business registration certificate. Since we use the San Francisco Department of Building Inspections’ building permit data as a key part of our contractor qualification and matching system, any information on business entities would basically be redundant with information they already have.

While this is favorable to BuildZoom, I still am convinced it creates an unfavorable situation for the many companies in San Francisco, who Cisneros is attempting to pressure into releasing their private user data, which must be frustrating for the Mayor’s office because it basically runs contrary to their mission of making San Francisco a safe haven for entrepreneurs and start-up’s.

Although I haven’t had a chance to meet or speak with Cisneros (he has ignored my repeated attempts to reach out), my impression is of someone who is more concerned with their personal track record when it comes to tax revenues – regardless of the net impact to the entrepreneurs and companies that make San Francisco one of the most innovative and vibrant cities in the country.

I also feel sympathy for the folks in the Mayor’s office who are working so hard to create a favorable environment in the city because they seem to have relatively little influence over how Cisneros chooses to interpret and execute on the tax codes.

Stay tuned for more developments.

November 1, 2017

Silicon Valley is the mecca of technological innovation in the world, however over the past decade or so, there has been a migration of companies into the city of San Francisco, due in large part to the allure that city living holds for young, talented candidates. Therefore, we moved to a small office on Market St once we had completed Y Combinator in the Summer of 2013.

Since then, we’ve changed offices several times yet remained in San Francisco. It is hard to quantify the value of being able to walk down the street to meet a prospective candidate, partner or investor, face-to-face. In spite of a challenging commute from the Peninsula, I have never regretted our decision to base BuildZoom in San Francisco – until recently.

Last August, we received a request from Simon Galindo, an ‘investigator/tax collector’, working on behalf of the San Francisco Treasurer & Tax Collector, in which they asked for information on independent contractors that provides services of BuildZoom or any related entity.

They cited Article, Section 6.5-1 of the San Francisco Business and Tax Regulations Code, which states:

In addition to a subpoena issued pursuant to Section 6.4-1, the Tax Collector may, at his or her discretion, send any person, whether as taxpayer, alleged taxpayer, witness, or custodian of records, a written request for financial information relevant to verifying, determining or redetermining any person’s tax liability or tax-exempt status. “Financial information” shall include, but not be limited to, bank records, journals, ledgers and local, State and federal tax returns, and shall include information regarding subsidiary, related, affiliated, controlled or controlling persons in possession of information relevant to the Tax Collector’s inquiry. The request shall be mailed to the person’s last known address as indicated in the Tax Collector’s records.

We responded by informing them that we did not engage in a formal business relationship with the contractors who used our service and they certainly were not ‘independent contractors.’ BuildZoom is an interactive computer service that (a.) aggregates and shares information from a variety of third-party resources, and (b) provides access to a computer service through which users may interact with one-another.

Thinking this was a simple mistake on their part, I hopped on a call with Mr. Simon Galindo, which I hoped would clarify things in short order and agreed to comply with their original request to provide information on independent contractors we had employed during the stated period. I was a bit surprised to find that he didn’t seem to care about the fact that contractors on our system were not independent contractors, nor did he care about our status as an interactive computer service. In spite of my assertions, he persisted in requesting our customer data (in addition to reminding us of a fine for not responding quickly enough to a prior request that was mailed to the incorrect address with an incorrect name).

It was at this point in time that I reached out to Jose Cisneros, the San Francisco treasurer in addition to Ed Lee with the following:

I did not receive a response from either. Operating in good faith and hoping to bring an abrupt resolution to the situation, we did look through our records and found that during the stated time period, we did not actually employe any independent contractors. Our explanation was sent back to the office and several weeks later, we received a follow-up from the office, which stated the following.

After stating repeatedly that we did not hire independent contractors, I finally got on the phone with Ms. Debra Lew and she consequently informed me that it didn’t matter whether or not BuildZoom had a former relationship with any contractors in the San Francisco, she wanted data on all contractors who had received an opportunity through BuildZoom who were based in SF, in addition to those based outside of SF who may have received opportunities that were based in San Francisco.

After responding that such a request seemed highly irregular because it not only deviated from the original request but also would compromise the privacy agreement we have with our users we are responsible for protecting, she simply responded by saying that she was responsible for protecting the tax payers in San Francisco and if we weren’t going to agree with their written requests, they’d be providing us with a formal subpoena.

Powered by a world-class team, the world’s largest collection of construction data, and an AI-enabled marketplace that is continually learning and improving the quality and efficacy of construction, BuildZoom is the platform upon which the cities and towns of tomorrow are built. Today, we’re doing this by creating transparency and accountability in our marketplace and our underlying mission is to help the millions of people that have been burned in the past. Most recently, we launched a campaign, specifically designed to help those ravaged by the disastrous fires in Sonoma County. We are trying to do good in the world.

Furthermore, we want to embrace San Francisco – after spending years in some of the world’s most prominent cities – London, Washington, DC, Seoul – I can honestly say that San Franciscans have a level of passion and commitment to the world that is unrivaled.

I’m honestly disappointed that instead of supporting its entrepreneurs and tech companies, the City and County of San Francisco is instead, thinking about how to exploit them to collect more tax revenue – even if it means crippling them in the process. I hope my fellow SF entrepreneurs will read this, share it and let your local politicians know that it is just not right.

In the meantime, I’ll keep writing about this situation as it happens.

After Y Combinator, we raised a small seed round and expanded from two to five. I rarely thought about Culture – after all, we were a tight-knit unit, working from morning until night, building something new and incredible. Initially, we worked in the living room of Dave’s home in Pac Heights and were in constant collaboration – we were like Voltron (apologies to the millennials out there for the outdated reference). Each morning, I couldn’t wait to get to Dave’s house, where our wolf pack was building something that was changing a huge market and touching millions of people.

As our team expanded, something peculiar began happening. Although most of our new teammates would integrate into the core team pretty seamlessly, there were several cases where things felt off. Inevitably, the the first firing took place and it absolutely sucked – I felt sick and suffered from insomnia for weeks before and after the act.

As we continued to grow, we began adding more members outside of the core engineering team and that peculiar feeling continued to grow until one day, I came into the office and realized that I wasn’t as excited about working with the team. After some reflection, I realized my dampened enthusiasm was entirely based on two folks we had hired.

The first, who I’ll refer to as Mr. 5pm, would inevitably start yawning at 4pm, begin checking his phone incessantly by 4:30pm and out the door at 5pm on the dot. The second, Mr. Dreamer, would come into the office each day with a new pie in the sky idea, completely oblivious to the mission at hand. Collectively, Mr. 5pm and Mr. Dreamer had somehow found a way to negatively impact my joy at building an incredible product and an incredible business.

In that moment, a classic NFL adage popped into my head: “Never draft for need; look for the best player available.”

Both Mr. 5pm and Mr. Dreamer had been hired to fill needs and we had fallen into the trap of thinking that it was preferable to fill a role with someone unspectacular as opposed to nobody at all. Thinking through the hiring process for Mr. 5pm and Mr. Dreamer, it was clear that in both cases, neither of us were particularly excited about the candidate but they seemed ‘good enough.’  This was a sharp contrast to the majority of past hires, who generally had us desperate to have them join the team.

It wasn’t long until both Mr. 5pm and Mr. Dreamer were gone and my unfettered joy at working with the team, returned immediately. It was then that Dave and I agreed to never make another hire unless we were both blown away by the prospect.

After our Series A, we continued adding to the team and found that our edict – to only hire when we were both blown away – was yielding consistently positive results, albeit it also meant that we were spending a lot of our time on candidate evaluation and not hiring at a rapid enough pace to keep up with a steadily increasing list of opportunities.

Around this time, I attended a dinner at Joe Lonsdale’s house (our lead investor and board member) and found myself sitting next to the great Scott Cook. I was struck by his otherworldly combination of cognitive acuity, humility and wisdom and I most likely annoyed the other dinner guests by bombarding him with a steady stream of questions. When the dinner ended, Scott approached me and to my amazement and delight, offered to visit BuildZoom and speak with the team.

The team was thrilled when I informed him that Scott would be visiting and peppered him with questions over the course of 1.5 hours. Although he shared a variety of anecdotes and lessons on that day, it was his answer to one question in particular that had a tremendous influence on how I think about culture.

I asked, “Are there any common attributes you’ve identified in the strongest members of your team?”

He thought for a few moments and then explained how in his early days, he made some hiring mistakes that took years to recover from and ultimately, came up with a simple framework to help evaluate talent: “First, I’ve noticed that the strongest performers have contagious energy. You can always tell when they are present because the energy in the room seems to increase. Second, they typically have incredibly high standards, exhibited in the work they produce and the expectations they place on their peers. Finally, they are the type of people with the underlying drive to work until the job is done; the concept of  a 9-5 day is foreign to them.”

Over the following weeks, Scott’s answer reverberated in my mind and kept popping up in conversations that Dave and I were having, about the company. Thinking back on our own successes and failures in hiring, I realized that we couldn’t use Scott’s exact framework but there was one that could predict whether someone would thrive or fail at BuildZoom.

After many months of back-and-forth, we ultimately were able to identify five characteristics in particular, which could be used to identify core BuildZoom team members. They are as follows:

1. Tenacity – In BuildZoom’s infancy, the founding team would work from morning to night and it wasn’t unusual for us to put in 70-80 hour weeks. Nobody forced us to work these hours, we were grinding because there was an incredible amount of work to do and we were all wired to work until the job was done. One of my mentors, Bill Wagner (currently the CEO at LogMeIn), once asked me whether my tenacity came from a desire for money or self-actualization. Over time, I’ve come to realize that tenacity can come from different places (I think there are more than the two Bill cited) and I’m not sure how much its etiology matters as long as it is present.

2. Scrappiness – This is an attribute that spawned out of our bootstrapping days, when we’d be maniacal about finding free, alternative solutions to solve problems when a paid option was available. Often, our hacked (and free) solution would outperform the status quo. Over time, I’ve come to realize there are times when scrapping has opportunity costs that simply aren’t worthwhile but to this day, when presented with a new challenge, our first instinct is to consider whether there is a way to beat the status quo.

3. Results before ego – I recall one day in particular, when I found Dave manually coding thousands of photos to build a ground-truth set for a classifier. Coming from a mid-market company with decent resources, my first reaction was to ask why Dave would be doing a job that we could outsource for $5/hour. Dave’s response was that it would take longer to find someone else to do the work and he wanted the classifier done on that day. Dave has an uncanny ability to eliminate all noise and hyper-focus on achieving results and I quickly learned that prioritizing ego over results, is a great way to fail.

When building something from scratch, you get your hands dirty – there is nobody to delegate to, nobody to share a process document with; there is just the action and its result. In the trenches, I found a secondary benefit – insight into opportunities hidden from view in the ivory tower. To this day, I make it a habit to work the support desk and engage directly with users on both sides of the marketplace and have no time for those who want to spend all their time in the ivory tower, delegating things ‘beneath them’ to others.

4. Data driven – At BuildZoom, we strive to operate with a sense of purpose. When we put a roadmap together, you can be sure of three things: First, that the items on the top of the list will have an impact on our KPI’s; second, they are grounded in strong business cases and supported by compelling data; and third, that once they have been deployed, we’ll be carefully evaluating their performance. One of my pet peeves is getting pitched an idea that is supported by data gathered from a sample of 1 (the person pitching the idea).

In our early days, I recall one meeting in particular, when a member of the team had been allocated significant engineering resources to develop a complicated internal tool that was intended to dramatically increase operational efficiency. After the tool had been deployed, we reconvened to evaluate its impact and when the evidence for its success was based on anecdotal feedback from several members of the business operations team. My question regarding its overall impact to efficiency was met with silence and after the meeting, I dove into the overall output metrics and quickly realized that not only had the tool not made a difference but half the team wasn’t even using it. Today, before we allocate effort to something new, we always ask the question, “If this is successful, how am I going to be able to prove it?”

5. High standards – We stole this one out of Scott Cooke’s playbook but it is an extremely strong predictor of whether or not someone will thrive at BuildZoom. Our general view is that if we can’t do something at the highest level, it is probably not worth doing. There are definitely cons to this approach – it certainly can result in a slower rate of growth; at the same time, we’ve seen several ‘rocket ship’ companies in our space, grow to 500-person companies one year, only to shrink to 10 the next. By maintaining high standards and operating with purpose and focus, we’re perpetually growing and improving. Ultimately, our high standards will be what allow us to dominate this market.

The first question came from a company that was providing custom implementations in a large, global industry and essentially helping companies in this industry to modernize their technology infrastructure through a combination of consulting services and technology.

They have a good sense for their wheelhouse customers and to date, many of their clients had come through the founder’s personal network. Their biggest problem was extending beyond this personal network through a scalable marketing and sales process. They had run some discrete experiments with direct sales and SEM but neither had been terribly ROI positive. What’s more, it sounds like a tightly contested market, which means their existing clients aren’t incentivized to provide referrals because from their point of view, they would be empowering those they view as competitors.

My two cents 

I’ll start with the caveat that this is not my area of expertise. I know some folks like Parker Conrad, formerly of Zenefits; Bill Wagner, CEO of LogMeIn; and Ben Rubenstein who is currently the CEO at OpCity, who are all far better equipped to address this type of question than myself. In fact, I’m currently going through a similar learning process in some ways.

That being said, here is what my intuition is telling me:

1. You know your target already – This is huge. If you truly understand the profile of the prospect you are trying to hit, this makes it easier to then map out the universe of entities with similar features. This should become your universe of prospects.

2. Play the role of an SDR – Instead of experimenting with a direct sales rep at this point, I might focus on playing the role of a great SDR and focusing on how to elicit the highest response rates from your universe of targeted prospects. Once you really understand how to convert the leads into warm leads, then think about bringing someone on to be a dedicated SDR. My intuition tells me

3. Play the role of a sales rep – You are going to be the best sales rep at this juncture. Look – you’ve already closed deals and have been generating revenue. Nobody knows how to pitch your start-up like you. Put your sales hat on and keep closing deals until you can’t keep up with the lead flow – then and only then – bring 2-3 sales reps onboard so they can operate with the playbook you’ve crafted. (Side note – don’t hire one sales rep if you can avoid it. Ideally, hire a few; at a minimum, hire two.

4. Don’t mess around with SEM right now – Some may argue with me here but I think you should be focusing on building a sales pipeline that is built to optimize the unit value of leads acquired. Only after you feel really good about your conversion rates through the funnel, will you have the information you need to understand how to think about acquisition costs via SEM.

If you have follow-up questions or disagreements, please post them below and I will address them as quickly as possible.

Having never hired a designer proactively, there were a lot of things I needed to learn in order to hire intelligently, which I’ll write about in the future. In the present, I’d like to share some general observations of things I believe worked (and didn’t work) from the perspective of a start-up founder, looking to hire designer #1.

#1. Think holistically about your portfolio We had pretty good lead flow at the top of our design applicant funnel. When you’re dealing with a large population of candidates, many folks including myself, will begin to look for opportunities to quickly filter. With design candidates, the most straight-forward heuristic was my initial impression of their portfolio. This was not only informed by the portfolio pieces but also by where it was hosted and how the portfolio itself, looked. The optimal portfolio was hosted on a personalized domain with a beautiful theme. If a portfolio was hosted on Weebly or Wix, it immediately tainted my impression. I’m not saying that Weebly and Wix aren’t great; I’d recommend either for SMBs but you are a designer. It’s actually better to showcase your work on Dribbble, Behance or even a PDF than on a free Website builder.

#2. You don’t need to put everything in your portfolio Just put your best and most recent work in your portfolio. There were several times my first impression of a portfolio was really positive but as I dug deeper, started seeing janky, dated work. More often than not, the work was just old and even though I could rationalize the lower quality, it still detracted from my overall experience of the portfolio.

#3. Be specific about your contributions There was nothing more frustrating than being excited to speak with a candidate with a gorgeous portfolio, only to find out the visual design was someone else’s work. Unless you explain the specific nature of your contribution to the work in your portfolio, my general assumption is that you were responsible for everything (unless you are really clear about what type of designer you are).

#4. Do some homework before the interview This is applicable to just about any role, but there is nothing more frustrating than having an initial conversation with a candidate and having them ask, “What do you guys do?” I always had more respect for candidates who had spent time looking through the site and developed a general sense for the existing design language (and business goals) so we could have a more focused and personalized discussion. I was really impressed when they had insightful recommendations or ideas that were based on research they had done.

#5. Don’t nitpick without offering solutions One of my favorite ways of learning how a designer thinks, is to walk through certain flows and get their feedback in real-time. I actually love critical feedback but found myself getting frustrated when the candidate would just tear everything apart without offering insight into how they would fix the problem.

#6. Don’t recommend changing everything I can recall one interview in particular where at one point, the designer bluntly stated, “I don’t really like the brand or the name. Have you thought about changing it?” When I probed to better understand their reasoning, the response was along the lines of, “It just doesn’t feel very exciting — I think one of the first things we should do is change the name.” Good founders have a roadmap that sits in the forefront of their consciousness. If they are talking with someone they just met, who doesn’t have an intimate understanding of their business, hearing a bunch of ‘critical’ things to do can be stressful. I’m not suggesting it isn’t worth articulating a perspective on what’s important but make sure to understand the roadmap and business goals before having this conversation.

#7. Understand the role of design within the company I personally believe that design needs to be a core strength in order for us to be successful. When it comes to the product, I think product management should advocate for the business; design should advocate for the user; and engineering should be responsible for determining what is actually possible. I also believe that design should have a seat at the table in helping structure the roadmap. Not every founder shares these beliefs. In the interview, it is imperative to understand the founder(s) perspective on design; how they value it; and how they believe design should work with both product and engineering. You could end up with a great comp package at a rocket ship company, feeling completely unfulfilled if the founders vision for design doesn’t align with your own.

#8. Quantify your impact (when possible) I love when designers talk about their work and proactively quantify their results against business goals. I definitely have found that ux and product designers do this with more frequency than visual designers, which makes it all the more impressive when visual designers are able to clearly articulate the impact they had. At the same time, I also like when I ask about the impact of a certain piece and the designer looks me in the eye and firmly states, “I just wanted to make it look and feel awesome.”

#9. Don’t talk about brand unless you know what it is I’ve had too many conversations with designers (particularly designers from NY) who obsess about the brand. Out of about 100 interviews with designers, I’d say at least 20 involved a recommendation to rebrand within the next year. My automatic response is, “Can you define what you mean by ‘brand’?” And I never really felt like I got an answer that made a whole lot of sense. I know that brand is a thing that matters and I know that it has profoundly benefited some companies. I also believe the obsession with ‘brand’ emerged from the Madison Avenue advertising culture, which primarily served large, consumer companies, operating in zero sum markets. In Silicon Valley, I think we need a new definition of brand (this is probably better suited to a future article). The bottom line is, don’t obsess over brand in an interview unless you have really thought critically about it and are able to clearly articulate a defensible position on what it is and how it will help.

#10. If you don’t obsess over user-centered design, you’re probably not a product designer We relentlessly study user behavior and elicit user feedback, to inform our approach to iteration. This has resulted in consistent improvement in our key metrics, but also some design that can seem counterintuitive at times. It is my belief that a true product designer, can balance left and right brain predilections. They should be able to synthesize user inputs and create something that balances product goals with aesthetic considerations. If there is something that functions well but looks odd, their inclination is to tell a better visual story without disrupting the essence of what is working. This type of designer is really hard to find. As a start-up with strong institutional ux sensibilities, I’d rather find a strong visual designer with great taste, who is interested in becoming a full-stack product designer; than a ux designer who needs to improve their visual design capabilities. Note: Thanks to Sean Shadmand for convincing me to try Medium and thanks to Deny for providing guidance on hiring.

Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt.

Dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

“User engagement and experience has become a major focus for any web-based service in recent years”

Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit as evidenced, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

So where to from here then?

Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt.

Dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

“User engagement and experience has become a major focus for any web-based service in recent years”

Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit as evidenced, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

So where to from here then?

Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt.

Dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

“User engagement and experience has become a major focus for any web-based service in recent years”

Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit as evidenced, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur

So where to from here then?

Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur